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Abstract 

Modern  commercial  aircraft  have  extensive  automation 
which  helps  the  pilot  by  performing  computations,  ob¬ 
taining  data,  and  completing  procedural  tasks.  The 
pilot  display  must  contain  enough  information  so  that 
the  pilot  can  correctly  predict  the  aircraft’s  behavior, 
while  not  overloading  the  pilot  with  unnecessary  in¬ 
formation.  Human-automation  interaction  is  currently 
evaluated  through  extensive  simulation.  In  this  pa¬ 
per,  using  both  hybrid  and  discrete-event  system  tech¬ 
niques,  we  show  how  one  could  mathematically  verify 
that  an  interface  contains  enough  information  for  the 
pilot  to  safely  and  unambiguously  complete  a  desired 
maneuver.  We  first  develop  a  nonlinear,  hybrid  model 
for  the  longitudinal  dynamics  of  a  large  civil  jet  air¬ 
craft  in  an  autoland/go- around  maneuver.  We  find  the 
largest  controlled  subset  of  the  aircraft’s  flight  envelope 
for  which  we  can  guarantee  both  safe  landing  and  safe 
go-around.  We  abstract  a  discrete  procedural  model 
using  this  result,  and  verify  a  discrete  formulation  of 
the  pilot  display  against  it.  An  interface  which  fails 
this  verification  could  result  in  nondeterministic  or  un¬ 
predictable  behavior  from  the  pilot’s  point  of  view. 


1  Introduction 

One  of  the  key  enabling  technologies  for  increased  au¬ 
tomation  in  human-machine  systems  is  verification , 
which  allows  for  heightened  confidence  that  the  sys¬ 
tem  will  perform  as  desired.  To  verify  system  safety , 
the  safety  specification  is  first  represented  as  a  desired 

1  Research  supported  by  a  National  Science  Foundation  Grad¬ 
uate  Research  Fellowship,  by  DARPA  under  the  Software  En¬ 
abled  Control  Program  (AFRL  contract  F33615-99-C-3014), 
by  the  DoD  Multidisciplinary  University  Research  Initiative 
(MURI)  program  administered  by  the  Office  of  Naval  Research 
under  Grant  N00014-00- 1-0637,  and  by  Grant  NCC2-798  from 
NASA  Ames  Research  Center  to  the  San  Jose  State  University 
Foundation,  as  part  of  NASA’s  base  research  and  technology  ef¬ 
fort,  human-automation  theory  sub-element  (RTOP  548-40-12). 


subset  of  the  state  space  in  which  the  system  should 
remain.  The  process  of  verifying  safety  then  involves 
computing  the  subset  of  the  state  space  which  is  back¬ 
wards  reachable  from  this  “safe  set”  of  states;  if  this 
backwards  reachable  set  intersects  any  states  outside 
the  desired  region,  then  the  system  is  deemed  unsafe. 
We  can  restrict  system  behavior  by  pruning  away  sys¬ 
tem  trajectories  which  lead  to  unsafe  states,  to  synthe¬ 
size  a  controller  which,  if  enforced,  guarantees  safety. 

In  the  past  several  years,  a  method  [1]  and  a  numerical 
tool  [2,  3]  have  been  developed  for  verifying  the  safety 
of  hybrid  systems.  Previous  work,  for  example  [4],  has 
focused  on  applications  of  hybrid  system  theory  to  fully 
automated  systems,  assuming  that  the  controller  itself 
is  an  automaton.  Here  we  consider  the  problem  of  con¬ 
trolling  semi- automated  systems,  in  which  the  automa¬ 
ton  and  a  human  controller  share  authority  over  the 
control  of  the  system  [5].  In  particular,  we  consider 
the  problem  of  verification  of  an  interface  between  a 
semi- automated  hybrid  system  and  a  human  controller, 
and  we  pose  the  question:  Is  the  information  displayed 
to  the  human  controller  about  the  hybrid  system  evolu¬ 
tion  sufficient  for  the  human  controller  to  act  in  such 
a  way  that  the  system  remains  safe?  We  consider  this 
problem  within  the  framework  of  an  example:  the  au¬ 
tomatic  landing  system  (autoland)  of  a  large  civil  jet 
airliner. 

The  autoland  system  of  modern  aircraft  is  one  of  the 
most  safety-critical  components,  and  is  subject  to  strin¬ 
gent  certification  criteria  [6].  Modeling  the  aircraft’s 
behavior,  which  incorporates  logic  from  the  autopilot 
as  well  as  inherently  complicated  aircraft  dynamics,  re¬ 
sults  in  a  high-dimensional  hybrid  system  with  many 
continuous  and  discrete  states.  Most  of  the  informa¬ 
tion  is  abstracted  away,  so  that  only  a  subset  of  this 
information  is  displayed  to  the  pilot.  Here,  we  are  in¬ 
terested  in  verifying  that  the  cockpit  interface  provides 
the  pilot  with  enough  information  so  that  the  pilot  can 
safely  land  or  safely  go-around. 
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2  Problem  Description 


\  glideslope  signal 


Figure  1:  Typical  landing  scenario. 


The  pilot’s  “user  model”  of  the  autoland  system,  based 
on  the  pilot’s  display,  manuals,  training,  and  personal 
experience,  is  necessarily  different  from  the  complete 
aircraft  “truth  model”  [7].  Discrepancies  between  these 
models  can  result  in  mode  confusion,  a  potentially  un¬ 
safe  situation  in  which  the  system  does  not  behave  as 
the  pilot  anticipates  [5,  8,  9].  Although  the  human 
factors  community  has  historically  dominated  research 
on  human- automation  interaction  [9,  10,  11,  12],  there 
have  recently  been  efforts  by  the  formal  methods  com¬ 
munity  [7,  13,  14,  15,  16]  as  well  as  system  and  control 
communities  [17]  to  address  these  safety-critical  prob¬ 
lems.  We  build  our  methodology  based  on  [7],  in  which 
user-interfaces  are  verified  for  a  given  task.  In  [7]  the 
hybrid  plant  model  is  represented  as  an  abstracted  dis¬ 
crete  system  in  which  the  system  dynamics  are  mod¬ 
eled  as  plant-triggered  (dynamic)  transitions.  It  is  not 
shown  there  how  the  discrete  representation  with  its 
dynamic  transitions  are  derived.  In  the  present  work, 
we  represent  the  plant  model  as  an  explicit  hybrid  sys¬ 
tem  and  show  how,  with  the  aid  of  a  control  component, 
the  detailed  transformation  into  the  equivalent  discrete 
representation  is  performed. 

In  this  paper,  we  first  develop  a  model  of  longitudi¬ 
nal  aircraft  dynamics  in  high-lift  configurations  used 
during  a  landing/go- around  procedure.  Using  a  com¬ 
putational  tool  for  hybrid  systems,  we  find  the  largest 
controllable  set  for  which  we  can  guarantee  the  aircraft 
can  both  safely  land  and  safely  go-around.  We  ap¬ 
ply  the  control  law  synthesized  from  this  computation, 
and  formulate  a  new,  safe  hybrid  automaton.  From 
this  automaton,  we  abstract  a  discrete  event  system 
which  represents  operation  in  the  regions  which  result 
in  safe  landing  or  go-around  maneuvers.  We  formu¬ 
late  the  interface  as  a  discrete  event  system,  as  well. 
Using  the  verification  techniques  described  in  [7],  we 
verify  the  interface  against  the  abstracted  procedural 
model.  Lastly,  we  discuss  implications  of  our  results 
and  directions  for  future  work. 


In  a  typical  autoland  maneuver  (Figure  1),  the  aircraft 
descends  towards  the  glideslope,  an  inertial  beam  which 
the  aircraft  can  track.  With  the  landing  gear  down, 
the  pilot  sets  the  flaps  at  Flaps-20,  the  first  high-lift 
configuration  in  the  landing  sequence.  After  capturing 
the  glideslope  signal,  the  pilot  increases  flap  deflection, 
stepping  through  both  Flaps-25  and  Flaps-30  by  the 
time  the  aircraft  reaches  1000’  altitude.  Near  50’,  the 
aircraft  leaves  the  glideslope  and  begins  a  flare  maneu¬ 
ver,  which  allows  the  aircraft  to  touchdown  smoothly 
on  the  runway  with  an  appropriate  descent  rate. 

If  for  any  reason  the  pilot  or  air  traffic  controller  deems 
the  landing  unacceptable  (debris  on  the  runway,  a  po¬ 
tential  conflict  with  another  aircraft,  or  severe  wind 
gusts,  for  example),  the  pilot  must  initiate  a  go-around 
maneuver.  A  go-around  can  be  initiated  anytime  after 
the  glideslope  has  been  captured  and  before  the  aircraft 
touches  down.  Pushing  the  go-around  button  engages  a 
sequence  of  events  designed  to  make  the  aircraft  climb 
as  quickly  as  possible  to  a  dialed-in  missed-approach 
altitude  which  the  pilot  usually  sets  to  2500’. 

2.1  Aerodynamic  Characteristics 

The  phases  of  landing  and  go-around  correspond  to 
fundamentally  different  operating  conditions  of  the  air¬ 
craft.  We  model  the  nonlinear  longitudinal  dynamics 
of  a  large  civil  jet  aircraft  by  x  =  fi(x ,  u),  in  which  the 
state  x  =  [V,  7,  h\  G  M3  includes  the  aircraft’s  speed  V, 
flightpath  angle  7,  and  altitude  h  (see  [18]): 


mV 

—D(a,  V)  +  T  coso  —  mg  sin  7 

mV  7 

— 

L(o,  V)  +  T  sin  a  —  mg  cos  7 

h 

V  sin  7 

(i) 

We  assume  the  control  input  u  =  [T,  a],  with  air¬ 
craft  thrust  T  and  angle  of  attack  a.  The  aircraft 
has  mass  m  =  190000  kg,  pitch  6  =  0  +  7,  and 
gravitational  acceleration  is  g  —  9.81  m/s2.  The  air¬ 
craft’s  lift  L(a,  V)  =  \pV2SCl(ol)  and  drag  D(a,  V )  = 
\pV2 SCd{ol)  depend  on  air  density  p  =  1.225  kg/m3, 
wing  surface  area  S  =  427.80  m2,  and  the  coefficients 
of  lift  and  drag,  Cl{ol)  =  Cl0  +  and  Cd(o)  = 

Cd0  +  KC^ia).  The  constants  Cx0 ,  Cd0,  and  K  were 
determined  for  the  particular  combinations  of  flap  set¬ 
tings  and  landing  gear  in  an  autoland/go- around  sce¬ 
nario  [18,  19,  20,  21,  22]  (Table  1).  CLa  =  5.105  in  all 
modes. 

2.2  Procedural  Automaton 

The  discrete  modes  of  our  hybrid  system  result  from 
the  combination  of  aircraft  dynamics  and  autopilot 
modes.  We  formulate  a  hybrid  procedural  model  based 
on  landing/go- around  procedures  a  pilot  is  trained  to 
follow.  We  focus  on  a  small  part  of  the  autoland  pro¬ 
cedure,  beginning  with  the  flare  maneuver. 


i 

Cl0 

Cd0 

K 

Flaps 

Setting 

Landing 

Gear 

1 

0.4225 

0.024847 

0.04831 

Flaps-20 

Down 

2 

0.7043 

0.025151 

0.04831 

Flaps- 2  5 

Down 

3 

0.8212 

0.025455 

0.04831 

Flaps-30 

Down 

4 

0.4225 

0.019704 

0.04589 

Flaps-20 

Up 

5 

0.7043 

0.020009 

0.04589 

Flaps-25 

Up 

6 

0.8212 

0.020313 

0.04589 

Flaps-30 

Up 

Table  1:  Aerodynamic  constants  for  autoland  modes  in¬ 
dexed  by  x  —  fi(x,u). 


Figure  2:  Hybrid  procedural  automaton  ^procedure- 


The  initial  state  of  our  procedural  model  ^procedure 
(Figure  2)  is  Flare,  with  flaps  at  Flaps-30  and  thrust 
fixed  at  idle.  As  instructed,  when  a  pilot  initiates  a  go- 
around  maneuver  (often  called  a  “TOGA”  due  to  the 
“Take- Off/Go- Around”  indicator  on  the  pilot  controls 
and  display),  the  pilot  changes  the  flaps  to  Flaps-20  and 
the  autothrottle  forces  the  thrust  to  Tmax  (Toga- Max). 
When  the  aircraft  obtains  a  positive  rate  of  climb,  the 
pilot  raises  the  landing  gear,  and  the  autothrottle  al¬ 
lows  T  G  [0,Tmax]  (Toga-Up).  The  aircraft  continues 
to  climb  to  the  missed  approach  altitude  ha it,  then 
switches  into  an  altitude-holding  mode,  Altitude  (with 
the  landing  gear  down).  If  a  go-around  does  not  occur, 
the  aircraft  switches  to  Rollout  when  it  lands.  (We  do 
not  model  the  aircraft’s  behavior  after  touchdown.) 

Although  go-arounds  are  unpredictable  and  may  be  re¬ 
quired  at  any  time  during  the  autoland  prior  to  touch¬ 
down,  cttoga  is  a  controlled  transition  because  the  pi¬ 
lot  must  initiate  the  go-around  for  it  to  occur.  Cer¬ 
tain  events  occur  simultaneously:  changing  the  flaps 
to  Flaps-30  and  event  otoga,  raising  the  landing  gear 
and  h  >  0,  and  lowering  the  landing  gear  and  h  >  hait. 

2.3  State  and  Input  Bounds 

Each  mode  in  the  procedural  automaton  is  subject  to 
state  and  input  bounds,  due  to  constraints  arising  from 
aircraft  aerodynamics  and  desired  aircraft  behavior. 
These  bounds,  shown  in  Table  2,  form  the  boundary 
of  the  flight  envelope  Wo-  Bounds  on  V  and  a  are  de¬ 
termined  by  stall  speeds  and  structural  limitations  for 
each  flap  setting  [22].  Bounds  on  7  and  T  are  deter¬ 


Mode 

V  [m/s] 

7  [degrees] 

a  [degrees] 

Flare 

[55.57,  87.46] 

[— 6.0°,0.0°] 

[—9°,  15°] 

Toga-Max 

[63.79,  97.74] 

[— 6.0°,  0.0°] 

[—8°,  12°] 

Toga- Up 

[63.79,  97.74] 

O 

CO 

CO 

0 

0 

,0, 

[—8°,  12°] 

Altitude 

[63.79,  97.74] 

[— 0.7°,0.7°] 

[—8°,  12°] 

Table  2:  State  bounds  for  autoland  modes  of  Hproce dUre- 


mined  by  the  desired  maneuver  [23].  Additionally,  at 
touchdown,  0  G  [0°,  12.9°]  to  prevent  a  tail  strike,  and 
h  >  —1.829  m/s  to  prevent  damage  to  the  landing  gear. 


3  Safety  Analysis 


The  state  bounds  just  described  define  flight  envelopes 
for  each  of  the  discrete  modes.  These  envelopes  are 
not  necessarily  controlled  invariant.  Thus,  we  need  to 
determine  what  subsets  of  these  envelopes  are  actu¬ 
ally  controllable  given  the  input  authority  available  to 
the  autopilot.  Because  the  nonlinear  dynamics  of  our 
model  (1)  make  analytic  determination  of  the  control¬ 
lable  subsets  impossible,  we  employ  a  previously  de¬ 
veloped  computational  algorithm  for  finding  controlled 
invariant  sets  for  this  problem  [3]. 


3.1  Computing  Reachable  Sets 

For  each  discrete  mode  of  the  autoland  system,  we  de¬ 
fine  the  target  set  as  the  region  outside  the  flight  en¬ 
velope  Wo,  denoted  (Wo)c  for  the  complement  of  Wo- 
Given  some  dynamically  evolving  system  and  some  tar¬ 
get  set,  we  define  the  backward  reachable  set  Wc(t)  as 
the  set  of  all  system  states  which  reach  the  target  set 
in  time  t.  The  autopilot  inputs  a  and  T  try  to  drive 
the  state  away  from  the  target  set,  to  keep  the  aircraft 
within  Wo- 

Computing  the  reachable  set  in  a  discrete  system  with 
a  finite  number  of  states — and  hence  a  finite  number 
of  possible  transitions — is  a  straightforward  but  possi¬ 
bly  time  consuming  task  of  enumerating  all  the  states 
which  have  a  path  to  the  target  set.  Computing  reach¬ 
able  sets  for  a  continuous  system  is  a  much  more  dif¬ 
ficult  undertaking;  for  example,  how  should  the  un- 
countably  many  states  in  any  nontrivial  target  set  be 
represented? 

An  algorithm  has  been  developed  for  computing  the 
reachable  sets  of  continuous  nonlinear  systems,  based 
on  a  time  dependent  Hamilton- Jacobi  (HJ)  partial  dif¬ 
ferential  equation  (PDE)  [2,  3].  For  x  =  /(x,  u),  x  G  X, 
input  u  EU  tries  to  keep  the  system  from  reaching  the 
target  set.  Define  a  continuous  function  Jo  :  X  — >  M 
such  that  (Wo)c  =  {xG  X|  Jq{x)  <  0}.  As  shown  in  [2], 


by  solving  the  terminal  value  HJ  PDE 


DtJ(x ,  t)  +  min[0,  H(x,  DxJ(x ,  t))]  =0  for  t  <  0; 

J(x,  0)  =  Jo{x)  for  t  =  0; 

(2) 

where  H(x,p)  =  ma xueupT  f(x,  u),  for  the  function  J  : 
X  x  (—oo,0]  — »  M,  we  obtain  an  implicit  representation 
of  the  reachable  set  Wc(£ )  =  {x  G  X| J(x,—t)  <  0}. 
The  state-dependent  control  synthesized  from  this  cal¬ 
culation  is  u*  (x)  =  argmaxnG^pT/(x,  u). 

Analytically  solving  (2)  for  a  general  Jo(x)  and  f(x,u) 
is  likely  to  be  impossible.  Computational  algorithms 
are  complicated  by  the  fact  that  for  even  smooth  Jq(x) 
and  f(x,u ),  the  solution  J(x,t)  can  develop  discontinu¬ 
ities  in  its  derivatives  after  finite  time,  and  hence  cease 
to  solve  (2)  in  a  classical  sense.  The  appropriate  weak 
solution  is  the  viscosity  solution  [24] ,  and  level  set  algo¬ 
rithms  [25]  are  numerical  techniques  developed  to  com¬ 
pute  such  solutions.  A  set  of  high  resolution  schemes 
[26]  have  been  designed  and  implemented  [3]  to  com¬ 
pute  J(x,£),  and  hence  the  boundary  of  the  reachable 
set  Wc(£),  very  accurately. 

3.2  Computing  Controllable  Flight  Envelopes 

In  any  given  mode  of  ^procedure  ,  the  aircraft  should 
remain  within  its  flight  envelope  Wo-  To  determine 
the  maximal  controllable  subset  W  of  Wo,  we  run  a 
reachable  set  computation.  The  reachable  set  typically 
converges  to  a  fixed  point:  Wc(£)  — >  Wc  as  t  — ►  Too. 
We  call  W  the  safe  flight  envelope.  Yet  the  full  autopi¬ 
lot  system  contains  transitions  between  modes,  and  so 
we  cannot  examine  any  mode  in  isolation. 

We  separate  the  hybrid  procedural  model  across  the 
user-controlled  switch  cttoga  into  two  hybrid  subsys¬ 
tems,  Hp  and  H- r,  shown  in  Figure  2.  Computation¬ 
ally,  automatic  transitions  are  smoothly  accomplished 
by  concatenating  modes  across  the  switch,  so  that  the 
change  in  dynamics  across  the  switching  surface  is  mod¬ 
eled  as  another  nonlinearity  in  the  dynamics.  Addition¬ 
ally,  we  assume  in  iT p  that  if  the  aircraft  leaves  the 
top  of  the  computational  domain  (h  =  20  m)  without 
exceeding  its  flight  envelope,  it  is  capable  of  reaching 
Altitude  mode,  which  we  consider  to  be  completely  safe. 

The  initial  flight  envelopes  (Wf)o  and  (Wt)o  are  deter¬ 
mined  by  state  bounds  on  each  mode  given  in  Table  2. 
We  perform  the  reachability  computation  on  Hp  and 
Ht  to  obtain  the  safe  flight  envelopes  Wf  and  Wt-  Fig¬ 
ure  3  shows  Wf,  and  Figure  4  shows  Wt  in  Toga- Up 
and  Toga- Max  modes.  (Note  that  the  boundary  of  Wf 
along  7  =  0  corresponds  with  the  transition  boundary 
of  Wt  between  Toga- Up  and  Toga- Max,  h  =  0.) 

Figure  5  shows  the  continuous  region  Wf  H  Wt  from 
which  we  can  guarantee  both  a  safe  landing  and  a  safe 
go-around.  Notice  that  this  set  is  smaller  than  Wf,  the 


Figure  3:  Safe  region  Wf;  the  outer  box  is  (Wt)o- 


v  (degrees)  50  v  (m/s) 

Figure  4:  Safe  region  Wt-  the  outer  box  is  (Wt)o- 

region  from  which  a  safe  landing  is  possible:  the  pilot 
is  further  restricted  in  executing  a  go-around.  There 
are  states  from  which  a  safe  landing  is  possible,  but  a 
safe  go-around  is  not. 


4  Interface  Verification 

A  general  verification  technique  for  analyzing  interfaces 
has  been  sought  for  many  years.  The  need  was  moti¬ 
vated  by  serious  incidents  and  accidents,  involving  hu¬ 
man  interaction  with  complex  automated  systems  (e.g., 
cockpit  automation).  Recently,  a  theory,  methodol¬ 
ogy,  and  a  detailed  verification  procedure  was  devel¬ 
oped  by  researchers  at  NASA  [7,  16].  The  methodol¬ 
ogy  considers  four  elements:  the  machine  model,  user 
model,  interface  model,  and  the  task  specification  (e.g., 
safe/unsafe,  multiple  modes).  In  this  section  we  use  the 
methodology  of  [7]  in  the  context  of  this  hybrid  system 
example. 

In  most  commercial  aircraft,  the  low-level  control  is 
performed  by  the  autopilot,  and  the  pilot  anticipates 
system  behavior  by  understanding  the  behavior  of  each 
autopilot  mode.  We  assume  an  automated  controller 
enforces  u  =  u*(x)  within  each  hybrid  subsystem.  By 
doing  so,  we  mimic  the  supervisory  role  pilots  have  in 
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Figure  5:  The  solid  shape  is  the  safe  region  Wf  fl  Wt, 
from  which  safe  landing  and  safe  go-around  is 
possible.  The  meshes  depict  Wf  and  Wt. 


Figure  6:  Ginterface  for  autoland/go- around  maneuver. 

Event  a i  occurs  when  h  =  0,  C3  when  h  >  ha it. 


highly  automated  aircraft,  including  the  option  not  to 
enforce  a  recommended  switch. 

The  pilot  activates  various  knobs,  buttons,  and  toggles 
to  change  the  system’s  mode.  Interaction  between  the 
pilot’s  actions  and  the  system’s  modes  are  encapsulated 
by  a  finite-state  machine  representation  of  the  inter¬ 
face  (^interface  =  (Q interface 5  ^interface 5  ^interface)-  Modes 
Q interface  are  determined  by  the  indications  on  the  dis¬ 
play;  events  E interface  are  determined  by  internal  tran¬ 
sitions  in  the  system,  or  by  the  pilot’s  actions.  The 
transition  function  is  interface-  The  interface  for  an 
autoland/go- around  is  shown  in  Figure  6. 

To  compare  the  interface  against  the  procedural 
model,  we  implement  the  controller  for  safety  u*(x)  in 
^procedure  and  create  a  discrete  abstraction  G*rocedure 
based  on  the  resultant  closed-loop  hybrid  system.  We 
partition  the  state-space  in  each  mode  into  the  interior, 
boundary,  and  complement  of  the  safe  flight  envelope  in 
that  particular  mode.  Across  the  user-controlled  switch 
0TOGA ,  we  partition  the  state  space  according  to  the  in¬ 
tersection  of  Wf  in  Flare  and  Wt  in  Toga-Up,  resulting 
in  nine  regions  in  each  mode.  Across  all  other  switches 
in  Hy  and  iTp,  we  enforce  safety  by  implementing  u*(x) 
so  that  trajectories  which  begin  inside  or  on  the  bound¬ 


ary  of  the  safe  flight  envelope  in  one  mode  will  remain 
within  or  on  the  boundary  of  the  safe  flight  envelope 
in  all  other  modes  in  that  hybrid  subsystem.  Only 
across  user-controlled  switches  can  the  system  become 
unsafe,  because  we  can  make  no  guarantees  about  the 
user’s  actions.  G*ptocedure  has  modes  Q;rocedure,  events 
^procedure-  and  transition  function  ^rocedure. 

We  verify  the  correspondence  between  Ginterface  and 
^procedure  according  to  the  verification  methodology  in 
[7].  We  associate  each  mode  in  Qinterface  and  Q*roCedure 
to  a  certain  specification  class  [7] .  Specification  classes 
are  a  way  of  indicating  a  type  of  behavior  or  quality 
of  the  system  -  for  example,  modes  which  the  system 
should  avoid  belong  to  a  specification  class  Unsafe. 

The  interface  and  the  abstracted  procedural  model  are 
related  through  their  events:  events  in  S*rocedure  map 
to  events  in  Einterface-  We  define  the  map  through 
^procedure  ^interface,  by  examining  the  events  in 

each  set  and  creating  a  correspondence  between  them 
by  hand  [7].  Events  in  £*rocedure  which  do  not  have  a 
corresponding  transition  in  Sinterface  map  to  the  empty 
event  s  [7]. 

The  two  systems  are  verified  through  the  creation  of 
a  composition,  defined  by  the  map  7 r.  The  composi¬ 
tion  (^composition  allows  us  to  keep  track  of  the  modes 
and  events  in  both  systems  (Ginterface  and  G£rocedure) 
at  the  same  time.  The  process  of  creating  the  composi¬ 
tion  uncovers  possible  problems:  error  states,  blocking 
states,  and  augmented  states  [7]. 

The  composition  begins  with  each  initial  state  in  each 
system  for  a  given  specification  class,  and  is  repeated 
for  each  pair  of  initial  states.  If  each  event  a  in 
G*rocedure  suc^  that  P  — ^  p'  bas  a  corresponding  event 

7r(a)  in  Ginterface  such  that  q  >  q' ,  then  the  composite 

state  (p,  q)  >  (p',  qf)  exists.  If  p  and  q  have  the  same 
specification  class,  and  p'  and  q'  have  the  same  speci¬ 
fication  class,  then  the  composition  continues  through¬ 
out  the  model.  An  error  state  exists  when  p'  and  q' 
have  different  specification  classes  [7]. 

Other  problems  occur  when  the  composition  fails.  If 
for  a  transition  a  E  ^procedure  from  P  p'  there  is 

no  corresponding  transition  q  g',  then  the  compo¬ 
sition  has  reached  a  blocking  state  [7].  (The  interface 
blocks  a  transition  which  occurs  in  the  abstracted  pro¬ 
cedural  model.)  Alternatively,  if  there  is  a  transition 

7 r(a)  E  ^interface  from  q  q'  but  no  corresponding 
transition  a  E  ^proCedure  from  P  ~ p\  then  the  com¬ 
position  has  reached  an  augmented  state  [7].  (The  in¬ 
terface  indicates  a  transition  which  is  not  possible  in 
the  abstracted  procedural  model.) 
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Figure  7:  Nondeterministic  behavior  from  the  pilot’s 
point  of  view. 


If  the  composition  fails  (due  to  blocking  or  augmented 
states),  or  if  the  composition  contains  error  states  (due 
to  mismatched  specification  classes)  then  the  interface 
is  not  an  adequate  representation  of  the  procedural 
model  [7]. 

Following  this  process  for  the  autoland  example,  we 
find  that  the  composition  Composition  contains  error 
states.  For  example,  if  the  pilot  initiates  a  go-around 
when  the  aircraft  is  in  WpnWrJ  in  Flare,  Composition 
reveals  specification  classes  (Flare, Flare) 

(Toga,  Toga).  However,  if  the  pilot  initiates  a 
go-around  from  Wp  fl  W%  in  Flare,  Composition 
reveals  specification  classes  (Flare,  Flare)  a12£|A 
(Unsafe, Toga).  From  the  pilot’s  point  of  view,  error 
states  appear  as  nondeterminism:  the  aircraft  some¬ 
times  behaves  as  the  pilots  expects,  but  sometimes  does 
not,  as  shown  in  Figure  7. 


5  Implications  and  Conclusion 

There  is  an  ongoing  debate  in  aviation,  space,  and  other 
safety-critical  industries  about  the  role  of  the  operator 
and  the  extent  to  which  automation  can  and  should 
be  used.  This  debate  has  been  fueled  by  incidents  and 
accidents  in  which  pilots  were  surprised  about  the  be¬ 
havior  of  the  automation.  While  the  debate  will  con¬ 
tinue,  it  is  clear  that  some  of  the  problems  in  human- 
automation  interaction  stem  from  design  problems.  In¬ 
terface  verification  methods  are  critical  for  identifying 
design  problems  early  on  in  the  design  phase.  Cur¬ 
rent  efforts  at  NASA  are  aimed  at  developing  methods 
for  extracting  the  machine,  interface,  and  user-models 
from  Java  code  and  then  applying  the  interface  verifi¬ 
cation  method  of  [7]  to  identify  error  states. 

Verification  within  a  hybrid  framework  allows  us  to  ac¬ 


count  for  the  inherently  complicated  dynamics  under¬ 
lying  the  simple,  discrete  representations  displayed  to 
the  pilot.  In  this  example,  in  order  to  safely  supervise 
the  system,  the  pilot  must  have  enough  information  to 
know  before  entering  a  go-around  maneuver  whether  or 
not  the  aircraft  will  remain  safe. 

The  interface  verification  methodology  begins  with  a 
procedural  model,  a  hybrid  system  which  incorporates 
discrete  mode  logic  as  well  as  nonlinear  continuous  dy¬ 
namics.  The  hybrid  safety  computation  provides  us 
with  continuous  control  restrictions,  which,  if  enforced, 
guarantee  that  the  system  will  always  remain  safe.  This 
guarantee  holds  to  within  the  accuracy  of  our  model. 
We  abstract  a  discrete  event  system  from  this  hybrid 
system  with  safety  restrictions.  To  do  so,  we  partition 
the  continuous  states  of  the  hybrid  system  with  safety 
restrictions  according  to  their  location  in  safe  or  unsafe 
regions  in  each  mode.  This  abstraction,  along  with  the 
formulation  of  the  interface  model  as  a  discrete  event 
system,  allows  us  to  use  existing  interface  verification 
techniques  [7].  We  compare  the  discrete  interface  and 
procedural  models  by  analyzing  their  composition  for 
error,  blocking,  and  augmented  states,  which  result  in 
confusing  and  unpredictable  behavior  from  the  pilot’s 
point  of  view. 

The  methodology  presented  here  also  extends  to  sys¬ 
tems  with  disturbances,  such  as  wind  or  an  engine  fail¬ 
ure.  While  verification  tools  can  aid  design,  we  also 
hope  to  contribute  directly  to  the  design  problem  (as 
in  [27]),  within  a  hybrid  framework. 
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